Systems and methods to create, compare, customize, promote, track, optimize and shop for portfolios of securities using social networks

ABSTRACT

A system and associated method for conducting security transactions includes a client device with a client interface configured to receive a client buy, sell, sell short, or buy to cover order from a client. The client is associated with a social media network and has at least one social network friend. A host server is coupled to the client device and executes logic resources for carrying out transactions for the client. A pricing engine and an inventory account are included. A targets engine determines a target number of long and shorted shares of a security to be held by the inventory account. A social networking engine allows clients to share information for at least one of, portfolios, orders and investment ideas. The social networking engine allows users to execute securities transactions based on the shared information.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of U.S. Application No. 61/592,088filed Jan. 30, 2012, and U.S. Application No. 61/608,479 filed Mar. 8,2012, both of which applications are fully incorporated herein byreference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to systems and methods forsecurities transactions, and more particularly to systems and methodsfor client securities transactions where a social networking engineallows clients to share information for at least one of, portfolios,orders and investment ideas, and the social networking engine allowsusers to execute securities transactions based on the sharedinformation.

2. Description of the Related Art

Currently, investors are limited in the ways in which the can customizeand shop for securities. Using existing systems, investors can purchaseindividual securities either online or through full service brokers.They can also purchase a variety of “actively managed” mutualportfolios. These are portfolios into which investors place theircapital and authorize a third party manager to invest such capitalwithout prior approval, but within the parameters defined by theportfolio mandate. Investors can also purchase exchange traded funds.These portfolios, however, are standardized and do not offer theinvestor the opportunity to customize them in any way.

Existing systems also lack a variety of client-friendly features thatwould not only make investing more accessible to the average consumer,but at the same time provide powerful tools for creating and managing aninvestment portfolio. For example, available tools fail to allow aclient to create a thematic portfolio based on a particular idea, or totag securities using an idea-based taxonomy. Further, current systemsgenerally display investment data in textual or tabular form, and do notprovide the data in graphical forms that facilitate comparison oranalysis of performance, risk, allocation, and other factors andstatistics.

Accordingly, there exists a need for client-friendly, intuitiveinvestment tools that address the shortcomings described above. There isa further need to provide systems and methods that allow clients tocreate, compare, customize, promote, track, optimize, and shop forportfolios of securities in real time and without aggregatingtransactions with third parties.

SUMMARY OF THE INVENTION

An object of the present invention is to provide systems and methods forclients to share information for at least one of, portfolios, orders,and investment ideas, and execute securities transactions based on theshared information.

Another object of the present invention is to provide systems andmethods to provide that securities transactions are shared from oneclient with a set of other clients and/or one or more external socialmedia sites.

Yet another object of the present invention is to provide systems andmethods where clients can communicate, collaborate, and collectivelybuild portfolios of securities.

A further object of the present invention is to provide systems andmethods that include a social networking engine to provide that aclient's positions can be viewed by a configurable set of other clients.

Another object of the present invention is to provide systems andmethods that include a social networking engine to provide that a clientcan comment as themselves or anonymously on a portfolio of securities.

Still another object of the present invention is to provide systems andwhere a client can create or customize lists of friends who are clientson the system and/or friends on one or more external social networksites.

These and other objects of the present invention are achieved in asystem for conducting security transactions. A client device with aclient interface is provided and configured to receive a client buy,sell, sell short, or buy to cover order from a client. The client isassociated with a social media network and has at least one socialnetwork friend. A host server is coupled to the client device andexecutes logic resources for carrying out transactions for the client. Apricing engine and an inventory account are included. A targets enginedetermines a target number of long and shorted shares of a security tobe held by the inventory account. A social networking engine allowsclients to share information for at least one of, portfolios, orders andinvestment ideas. The social networking engine allows users to executesecurities transactions based on the shared information.

In another embodiment of the present invention, a method for conductingsecurity transactions provides a system with a client device with aclient interface, an inventory account and a social networking engine. Aclient order is received. The social networking engine allows clients toshare information for at least one of, portfolios, orders and investmentideas. The social networking engine allows users to execute securitiestransactions based on the shared information.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an overall block diagram illustrating one embodiment of asystem of the present invention.

FIG. 2 is a flow chart illustrating one embodiment of an indexconstitution process.

FIG. 3 illustrates one embodiment of the creation of a finalshare-weighted portfolio, construction and optimization.

FIG. 4 is a snapshot of one embodiment for manipulation of a client'slong only security portfolio kept at balance at all times that isimplemented at the client interface.

FIG. 5 is a snapshot of one embodiment for customization of ashare-weighted portfolio construction that includes long and shortweights.

FIG. 6 is a flowchart illustrating an embodiment of auto balancing aclient's portfolio in response to a security weight adjustment.

FIG. 7 illustrates an embodiment of the logic applied to determine howto distribute a weight change among the other securities.

FIG. 8 illustrates an embodiment of auto balancing logic in response toa segment weight change requested by a client.

FIG. 9 illustrates an embodiment of the logic when a weight of thesegment is being increased.

FIG. 10 illustrates an embodiment of how the other segment weights areupdated.

FIG. 11 illustrates an embodiment of the logic applied when the weightof a segment is being decreased.

FIG. 12 is a flowchart illustrating how a customer that desires topurchase a share-weighted portfolio connects using the client interface.

FIG. 13 is a flowchart for a fraction, whole share, or whole share withfraction buy order.

FIG. 14 illustrates an embodiment of a process that determines whetheror not the inventory can and should fill all, part, or none of the orderfor buy market orders.

FIG. 15 illustrates one embodiment of a process that determines whetheror not the inventory can and should fill all, part, or none of the orderfor buy limit orders.

FIG. 16 illustrates if an order is not marketable, a decision is made asto whether or not filling from inventory is more or less beneficial tothe system than executing at market.

FIG. 17 illustrates that in the case of a both no-inventory andfraction-only results eager fill logic resources are run to determine ifthe system desires to bunch an inventory order with the client order torefill the inventory to its target balance in the security.

FIG. 18 illustrates an embodiment of how the pricing engine logic pricesbuy orders.

FIG. 19 is a flowchart illustrating one embodiment of a customer sellorder flow.

FIG. 20 illustrates an embodiment of the system routing a sell orderthrough a logic resource that decides whether or not the full order,only the fraction component of the order, or no part of the order willbe acquired in the inventory account.

FIG. 21 illustrates an embodiment of how the pricing engine logic pricessell orders.

FIG. 22 illustrates an embodiment of details of the decision process onhow much will be acquired by the inventory account for a sell marketorder.

FIG. 23 illustrates one embodiment of the logic for sell limit orders.

FIG. 24 illustrates an embodiment of targets engine operation.

FIG. 25 illustrates an embodiment of the system providing fractionshorting.

FIG. 26 illustrates an embodiment of a process that determines whetherthe inventory account can and should allocate all, part, or none of anorder for market sell short orders.

FIG. 27 illustrates one embodiment of a process that determines whetherthe inventory account can and should fill all, part, or none of a sellshort limit order.

FIG. 28 illustrates one embodiment of logic resources run to determineif the system wants to bunch an inventory short order with a clientorder to reload the inventory to its target short position in asecurity.

FIG. 29 illustrates an embodiment of how the pricing engine logic pricessell short orders.

FIG. 30 illustrates an embodiment of the system routing a buy to coverorder through a logic resource that decides whether or not the fullorder, only the fraction component of the order, or no part of the orderwill be covered from the inventory account.

FIG. 31 illustrates an embodiment of how the pricing engine logic pricesbuy to cover orders.

FIG. 32 illustrates an embodiment of the details of a decision processon how much will be covered from the inventory account for a covermarket order.

FIG. 33 illustrates an embodiment of the logic for cover limit orders.

FIG. 34 is a flowchart for a customer that desires to rebalance ashare-weighted portfolio and connects through the customer interface.

FIG. 35 is an embodiment of a flowchart of a customer buy trigger orderflow.

FIG. 36 illustrates one embodiment of the handling of buy triggerorders.

FIG. 37 illustrates one embodiment of a customer sell trigger orderflow.

FIG. 38 illustrates one embodiment of a submitted sell trigger order.

FIG. 39 illustrates an embodiment of a flow for a customer desiring tobuy a hedged share-weighted portfolio.

FIG. 40 illustrates further details for hedging.

FIG. 41 illustrates an embodiment of tax loss harvesting.

FIG. 42 illustrates an example of a share-weighted portfolio order.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following description is presented to enable one skilled in the artto make and use the share-weighted portfolios, and is provided in thecontext of particular applications and their requirements. Thus, thefollowing description of embodiments consistent with the presentinvention provides illustration and description, but is not intended tobe exhaustive or to limit the present invention to the precise formdisclosed. Various modifications to the disclosed embodiments will beapparent to those skilled in the art, and the general principles setforth below may be applied to other embodiments and applications. Forexample, although a series of acts may be described with reference to aflow diagram, the order of acts may differ in other implementations whenthe performance of one act is not dependent on the completion of anotheract. Further, non-dependent acts may be performed in parallel. Note thatany of the methods described herein may be performed by hardware,software (including microcode), firmware, or any combination thereof.For example, a storage medium may store thereon instructions that whenexecuted by a machine result in performance according to any of theembodiments described herein. Thus, the present invention is notintended to be limited to the embodiments shown and the inventor regardshis invention as any patentable subject matter described.

FIG. 1 illustrates one embodiment of a system 10 of the presentinvention. The system 10 includes, a client device 12 with an interface,a host server 14, inventory account 16, pricing engine 18, targetsengine 20 and a trading engine 22.

The system 10 can also include a balancing engine that is configured toprovide for adjustment of weight for a group of securities. The system10 can also include a social networking engine, a research engine and athird party publisher device. The research engine can include logicresources used to build and customize pre-packaged share weightedportfolios of securities.

In various embodiments, the client device 12 can be a smart or dumbterminal, network computer, personal digital assistant, wireless device,smartphone, tablet, game machine, music player, mobile telephone,laptop, palmtop, wireless telephone, information appliance, workstation,minicomputer, mainframe computer and other computing device. In oneembodiment, the user interface has application logic implemented as partof the interface presented to the client device 12. In one embodiment,the client interface is a web page rendered on the client device 12 thatincludes interactive components, text, graphics, sounds, and links toother web pages. The client uses the interface to research and analyzecurrently owned and desired securities/portfolios and to communicatetheir intention to the host server 14.

In one embodiment, the inventory account 16 holds the securities bought,or sold short. In one embodiment the inventory account 16 is associatedwith an order management system 10 that can include, logic resources,databases and communication infrastructure used to receive, analyze,route, and execute client buy, sell, sell short, and buy to covershare-weighted portfolio orders.

In one embodiment, the host server 14 has hardware resources coupledwith software resources, including a web server that receives a clientweb request, delegates the request to appropriate hardware or logicresources for processing and communicates the resulting response to theclient device 12. In one embodiment, the host server 14 includes adatabase that stores at least one of historical market data, third partydata, client account data, positions data, customized portfolio data andpre-packaged portfolio data. This database is in communication with thetrading engine. The database provides access to data in response torequests received from the client device 12. In one embodiment, the hostserver 14 is configured to receive requests for dynamic advertisement.

The targets engine 20 includes logic resource that calculates the targetnumber of long and short shares of a security to be held in theinventory account 16, and the like.

In one embodiment, the trading engine is a combination of hardware,logic, and communication resources that executes a client request forthe purchase and sale of securities through a combination of routing oforders to market venues and/or allocations from the inventory account16. The trading engine can include, pricing, reservation costoptimization, buying power and the like. The trading engine isconfigured to provide return communications with the client device 12with regard to status or execution of a transaction. In one embodiment,the targets engine 20 includes logic resources that uses probabilisticmodels to compute target long or short positions for each security inthe inventory account 16.

A trading database, with hardware resources in conjunction with softwareresources, can be associated with the trading engine and used to storedetails on client and system 10 transactions.

In one embodiment, the pricing engine 18 includes networkinfrastructure, hardware, and logic resources used to determine realtime market prices for securities ordered by a client. The pricingengine 18 calculates a current market price of shares of a security.

Market data is utilized that is pricing data obtained from market venuesthat quantifies the valuation of securities.

In one embodiment, the research engine includes portfolio creation andoptimization logic resources used to determine final share-weightedportfolio constituents as a subset of an idea index and to computeweights for constituent securities in a final thematic share-weightedportfolio. In one embodiment, a research database includes hardwareresources in conjunction with software resources used to storefundamental and pricing data on securities.

In one embodiment, a clearing firm can be used by the system 10. Theclearing firm is a financial organization that handles trades,settlement and delivery of stocks and securities.

The system 10 can include a pre-packaged portfolio database withhardware resources in conjunction with software resources used to storethematic share-weighted portfolio constituents. A user database isincluded with hardware resources in conjunction with software resourcesused to store client details and their respective positions.

The system 10 can also include an optimizer that is a logic resourceused to compute weights for constituent stocks in a final motif.Security weights in the share-weighted portfolio are chosen to minimizehistorical tracking error between a final share-weighted portfolio andthe idea index while maintaining the risk-return characteristics of theidea index. A pre-packaged share-weighted portfolio constructor is alogic resource used to determine final share-weighted portfolioconstituents as a subset of the idea index.

An order flow data aggregator can be provided that has logic resourcesto analyze historical share-weighted portfolio transaction data andcompute aggregated statistically relevant measures.

In one embodiment, the system 10 includes user accounts which arerecords of a client's portfolio positions and transaction history thatis maintained and stored using the system's logic and hardwareresources.

The system 10 can also include an order overlay that is an open orderoverlay is a data resource that tracks un-executed orders that will havea net impact on the inventory account 16 if and when they are executed.

An outer-flow is a reference in the child logic resource to the parentlogic resource where the parent requests a response or decision based onthe input fed to the child.

In one embodiment, the system 10 has a target number of shares forconducting security transactions. The client device 12 with clientinterface receives a client buy, sell, sell short, or buy to coverorder. The host server 14, coupled to the client device 12, executeslogic resources for carrying out transactions for the client. Thetargets engine 20 determines a target number of long and shorted sharesof a security to be held by the inventory account 16. The trading engineprocesses the client buy, sell, sell short, or buy to cover order. For abuy order the trading engine fills the buy order for both whole andfraction shares from the inventory account 16 if there is sufficientinventory in the inventory account 16. When there is insufficientinventory for the buy order, the trading engine completes a purchase offraction shares first from the inventory account 16 and then purchasesthe remainder of the buy order from the market. When the inventoryaccount 16 can not fill any of the buy order, the trading enginepurchases the entire buy order from the market and in the same orderpurchases a target of shares set by the targets engine 20 for theinventory account 16. An associated method is provided.

In one embodiment, the purchase and sales of securities for theinventory account 16 is made in conjunction with a client order. Inanother embodiment, the client order is selected from at least one of, athematic share-weighted portfolio, customization or modification of adefault share-weighted portfolio, purchase of a share-weightedportfolio, and selling of an owned share-weighted portfolio.

In another embodiment, for a sell order the trading engine sells a wholeand fraction number of the shares of a security to the inventory account16 when a sum of the inventory account's 16 current balance and a sizeof the order is less than or equal to the inventory account's target.The trading engine sells only a fraction to the inventory account 16 andsends a whole component of the order to market if the inventoryaccount's balance is near its target and cannot buy the whole componentof the order. The trading engine increases a size of a market sell orderby 1 to reduce the inventory account balance when the inventory accountbalance has exceeded the target set by the targets engine 20.

For a short sell order, the trading engine fills the short sell orderfor whole and fraction shares from the inventory account 16 if there issufficient short inventory in the inventory account 16. When there isinsufficient inventory in the inventory account 16, the trading enginecompletes the short sell of fraction shares first from the inventoryaccount 16 and then shorts the whole component of the short sell orderfrom the market. When the inventory account 16 can not fill any of theshort sell order the trading engine shorts the entire short order fromthe market and also shorts a target of shares set by the targets engine20 for the inventory account 16.

For a buy to cover order the trading engine acquires an obligation of aborrowed whole and fraction number of the shares for the inventoryaccount 16 when a sum of the inventory account's current balance and asize of the order is less than or equal to the inventory account's shorttarget. The trading engine acquires the obligation of the borrowed ofonly the fraction to the inventory account 16 and sends the wholecomponent of the order to market if the inventory account's balance isnear the target. The trading engine increases a size of a market buy tocover the order by 1 to reduce the inventory account's short balancewhen the inventory account balance has exceeded the short sell target.

In another embodiment, the trading engine is configured to process theclient buy, sell, sell short or buy to cover order. The trading engineenables the trading of fraction shares in real time as well as reducesthe frequency of orders sent to market by executing principal tradesagainst the inventory account 16. A corresponding method is provided.

In another embodiment, the targets engine 20 calculates a target numberof long and short shares of a stock to be included in the inventoryaccount 16 to meet present and future buy, sell, sell short, and buy tocover client orders. A corresponding method is provided. In oneembodiment, lower targets are set for thinly traded stocks. In anotherembodiment, the targets are set in response to a probabilistic model forfuture orders. In another embodiment, predicted order flow and clientorder flow are both used to calculate the targets.

In another embodiment, the balancing engine allows a client tomanipulate the client's security portfolio and keep it in balance at alltimes. The balancing engine provides that any constituent moved by aclient remains at a declared level and remaining constituents areproportionally balanced so that the sum of the weights adds to 100%. Anassociated method is provided. In another embodiment, positive andnegative weights can be adjusted to represent long or short exposure toan underlying security, with the sum of an absolute value of thenegative and positive percentages adding to 100%. In another embodiment,a declared weight level of a security can be overridden by clientadjustment. In another embodiment, a client can disable declared weightlevels for a given constituent. In another embodiment, errors aredisplayed to the client when the declared weight level of a constituentprevents the desired action

In another embodiment of the present invention, the targets engine 20determines a target number of long and shorted shares of a security tobe held by the inventory account 16. The trading engine processes arebalance order of the client's portfolio. The client receives a list ofcurrent positions, selects a share-weighted portfolio, chooses analternate weighting, and decides to: (i) add funds, (ii) remove funds or(iii) rebalance the share-weighted portfolio. A corresponding method isprovided. In another embodiment, logic resources are applied tocalculate a set of buy, sell, buy to cover, or sell short orders tofulfill the client's alternate weighting scheme as well as add to,remove from, or retain the amount of capital specified by the client.

In another embodiment of the present invention, the trading engineprocesses a client index or theme based basket order as a single order.The trading engine enables the trading of fraction shares in real timeas well as reduces a frequency of orders sent to market by executingprincipal trades against the inventory account 16. A correspondingmethod is provided. In one embodiment, the client's order is based on apre-packaged or customized thematic share-weighted portfolio.

In another embodiment of the present invention, the trading engineprocesses a client order for hedging of market exposure or harvesting oftax losses. The trading engine enables the trading of fraction sharesand reduces a frequency of orders sent to market by executing principaltrades against the inventory account 16. A corresponding method isprovided.

In another embodiment of the present invention, the social networkingengine allows clients to share information for at least one of,portfolios, orders and investment ideas. The social networking engineallows users to execute securities transactions based on the sharedinformation. A corresponding method is provided. Users can communicate,collaborate and collectively build portfolios of securities. In oneembodiment, the social networking engine is configured to provide that aclient's positions can be viewed by a configurable set of other clients.In another embodiment, the social networking engine is configured toprovide that a client can comment as themselves or anonymously on aportfolio of securities. In one embodiment, the social networking engineis configured to provide that a client may create or customize lists offriends who are clients on the system 10 and/or friends on one or moreexternal social network sites. In one embodiment, the social networkingengine is configured to provide that a client can adjust privacy filtersto enable or prevent a sharing of the client's positions, orders, andcomments with one or more lists of friends. In another embodiment, thesocial networking engine is configured to provide that clients can flagother user's comments as inappropriate. In another embodiment, thesocial networking engine is configured to provide that flagged commentscan be removed based on statistics about the comment, number of times itwas flagged, and the clients who flagged the comment.

In one embodiment of the system 10, the trading engine processes theclient order in real time. In another embodiment, the trading engineprocesses client orders independently from other clients. In yet anotherembodiment, the trading engine does not net client orders whenprocessing client orders. In one embodiment, the pricing engine 18provides a market price of shares transacted from the inventory account16.

Referring to FIG. 2, a flow chart of the Index constitution process isillustrated. An identifying theme is used and companies are found in theequities universe that have exposure to the selected theme. The publicSEC filings and reports on the relevant firms are researched todetermine each firm's exposure to the theme. A uniform metric such asrevenue, operating income etc. is found that quantifies exposure of eachfirm in the Idea Index to the theme. A purity premium factor is thenapplied that further scales down the weight for firms that have arelatively small exposure to the theme. A thematically weighted Index isthus created and is used as an input for share-weighted portfolioconstruction.

The creation of a final share-weighted portfolio (construction andoptimization) is illustrated in FIG. 3. An Idea that includes eachrelevant firm's ticker, segment and weight is input to a share-weightedportfolio optimizer. The share-weighted portfolio optimizer uses a riskmodel which is a model of historical stock returns in terms ofmacroeconomic conditions, valuation factors and sector returns. Theshare-weighted portfolio constructor decides the composition of thefinal share-weighted portfolio to provide the maximum diversificationpossible using the stocks from the Idea Index. The optimizer applies aconstrained minimization algorithm to decide the weights of the stocksin the final share-weighted portfolio such that the tracking error ofthe final portfolio with respect to the Index is minimized whilemaintaining the same risk-return characteristics as the Idea Index. Theoutput from the share-weighted portfolio optimizer is the finalthematically weighted pre-packaged portfolio.

In one embodiment, share-weighted portfolio order customization useslogic resources that are implemented to allow, (i) weight modificationof each segment, (ii) weight modifications for individual stocks inshare-weighted portfolio, (iii) deletion of stocks, (iv) one-clickdeletion of all stocks in a segment and (v) the addition of stocks notincluded in the original construction. In all cases logic resources areimplemented to automatically balance the construction such that the sumof the weights of the segments as well as the sum of the weights of thestocks remains 100%.

FIG. 4 is a snapshot of one embodiment for manipulation of the client'slong only security portfolio and keep it in balance at all times that isimplemented at the client interface. As shown, motif segments, includingbut not limited to Marketplace, E-tailers, Travel, Media and the likeare listed. A slider, or other equivalent structure, is included toenable the client to adjust a segment weight. A button or otherequivalent structure is provided for the client to add other stocks. Abutton, or other equivalent structure, is provided for the deletion ofall stocks in a segment, as well as for the deletion of a stock, and thelike. A slider, or other equivalent structure, is also included toadjust an individual stock weight inside a segment. Additionallybuttons, or other equivalent structures, are provided to enable settingof declared levels for segment weights and stock weights such that theirvalues are not changed when auto balancing logic is engaged.

FIG. 5 is a snapshot of one embodiment for customization of ashare-weighted portfolio construction, for long and short, that isimplemented at the client interface. Sliders or equivalent structuresare provided for the selection of long and short weights. Sliders orequivalent structures are provided for, selecting a net segment weight,as well as for the selection of a long weight and selection of a shortweight for an individual security.

FIG. 6 is a flowchart illustrating an embodiment of auto balancing aclient's portfolio in response to a security weight adjustment. Theclient adjusts a security weight by ΔSW. If there aren't othersecurities with weights set at declared levels, then the system 10cannot make the requested adjustment and will return an error message tothe client, else the direction of the change is evaluated.

If the change is an increase in weight, the sum of the security weightsof securities whose levels have not been set by the client is computed.If there is not a sufficient amount of unlocked weight then the weightchange adjustment requested by the client is reduced to the amountavailable. In either case the modified or unmodified change is appliedto the security's weight and the user interface components are updated.Once the change has been made to the security itself the weights of theother securities and segments must be computed.

The logic applied to determine how to distribute the weight change amongthe other securities is illustrated in FIG. 7. The logic is passed inthree pieces of data: whether or not to allow the modification ofweights for securities that have been set at declared levels, the set ofsecurities to be modified, and the amount to apply across the set ofsecurities passed in. The logic first determines if there are anyunlocked securities that do not have weights set at levels declared bythe client. If there are unlocked securities then, the set of securitiesis filtered to only include the unlocked securities. The sum of theseunlocked securities is computed. For each of securities to be adjusted,the adjustment is calculated as the weight of the security divided bythe sum of the weights of the securities to be adjusted multiplied bythe total amount to apply across the set of securities. Thisproportional adjustment is then added to the security's weight and theuser interface elements related to the security are updated with the newvalues. However, if there are no unlocked securities in the set ofsecurities passed then the logic checks whether it is allowed to modifythe weights of locked securities whose weights have been set at declaredlevels by the client. If it is not allowed to modify the weights oflocked securities, the logic then returns an error to the client. If themodification of locked securities is allowed, then the locked securitiesare used as the set of securities to be adjusted. This set of securitiesthen follows the aforementioned logic to calculate and apply theproportional adjustment to each security.

Once the logic illustrated in FIG. 7 is applied to the remainingsecurities, the segment weights are recalculated as the sum of theweights of the securities within each respective segment. The userinterface elements related to the segments are subsequently updated.

FIG. 8 illustrates an embodiment of auto balancing logic in response toa segment weight change requested by the client. The logic firstdetermines whether or not there are other unlocked segments. If thereare no other unlocked segments than the requested modification cannot bemade and an error is returned to the client. If there are other unlockedsegments, then the quantity change is evaluated to determine whether theclient is requesting to add weight, subtract weight, or make no changeto the segment. When the requested change is zero, the logic returnsimmediately to the client since no change has been requested.

FIG. 9 illustrates the logic when the weight of the segment is beingincreased. The logic first computes the sum of the unlocked weights thatare not in the segment that is being changed as the weight available tochange. The weight available to change is compared to the changerequested. If the weight available to change is less than the requestedchange than the requested change is reduced to the weight available tochange. The requested change is then applied to the segment beingmodified and the user interface elements associated with that segmentare updated to reflect the new value. The requested change is thenpropagated to the securities within the segment not allowing anysecurities that have been set at declared levels to be modified. Thelogic for distributing an arbitrary weight to a set of securities isillustrated in FIG. 7 and described above. Finally, the negation of therequested change is proportionally distributed to the other segments.

FIG. 10 illustrates how the other segments weights are updated. Thelogic here takes in a set of segments to be modified, along with theamount with which to modify the segments. Since the calling logic alwaysnegates the amount passed in to this flow, the change requested herewill always be a negative value. The logic first sets a remainder valueto zero. The remainder value will later be used in a recursive manner tocalculate the appropriate proportional distribution for each segment.With an unlocked segment defined as a segment that has one or moreunlocked security, the logic sums these unlocked segment weights. Foreach of the unlocked segment, the sum of the unlocked securities withinthe segment is computed. The logic then computes the amount by which thesegment should be adjusted. This amount is defined as the currentsegment's weight divided by the sum of the unlocked segments multipliedby the requested overall change.

The minimum of zero and the sum of the segment adjustment and the sum ofthe unlocked segment weights is added to the current value of theremainder. This amount represents the change that could not be appliedto the segment proportionally due to some of the securities within thesegment being set at declared levels by the client (and thereforeun-modifiable). The segment weight is updated by adding the maximumvalue of the segment change and the negation of the sum of the unlockedsecurity weights within the segment to its current value. Since bothvalues are negative, the least negative number will be returned by themaximum evaluation and the segment will always go down in weight. Theuser interface elements associated with the segment are updated toreflect the new value.

The change to the segment is then proportionally distributed to theunlocked segment as described in FIG. 7 and described above. Once allsegments have been updated, the remainder must also be distributedproportionally. This distribution is performed by setting the changerequested to the remainder, resetting the remainder to zero and loopingover the segments again distributing the remainder to the segments inthe same manner as described earlier. The recursive loop ends when thereis no longer a remainder and the logic is complete and returns.

FIG. 11 illustrates the logic applied when the weight of the segment isbeing decreased. The amount of the decrease is first added to therequested segment and the associated user interface elements are updatedto reflect the new value. The change is applied to the securities withinthe segment allowing security weights that have been set at declaredlevels by the client to be modified. The process for distributing theweight among the securities in the segment is illustrated in FIG. 4 anddescribed above. The logic then computes the sum of the other unlockedsegments. For each of the other unlocked segments the proportionalweight change to be applied is calculated as the segment weight dividedby the sum of the unlocked segment weights, multiplied by the negationof the requested change. This weight change is applied to the weight ofthe segment by adding its value to the weight of the segment. The userinterface elements associated with the segment are updated to reflectthe new value. The change must then be distributed to the securitieswithin the segment. The logic that proportionally distributes the changeis illustrated in FIG. 4 and described above. Once all segments havebeen modified, the logic is complete and returns.

In the FIG. 12 flowchart, a customer desires to purchase share-weightedportfolio connects using the client interface. The customer receives alist of available share-weighted portfolios and selects an existing ornew share-weighted portfolio. If the share-weighted portfolio is new,securities are added, removed, and the customer customizes theirweights. Once the customer is satisfied with the construction they haveproduced, market data is sourced to securities in the share-weightedportfolio. The number of shares is computed for each security whilemaintaining weighting of the construction and fulfilling a desireddollar amount. Orders are created for each security and quantity. Ordersfor each security are sent to the order management system. The buy flowis then followed, including that for fraction shares described herein.When the customer selects an existing share-weighted portfolio, thecustomer selects whether to “buy as is” or to customize. Forcustomization, the customer customizes the weights, adds securities, orremoves securities until the desired construction is produced. Thecustomized weights are then sent for sourcing of market data of thesecurities.

In various embodiments, the client transactions are done in real time. Aclient device 12 has a client interface that in operation is configuredto receive at least one of, a client buy, sell, sell short, or buy tocover order. The host server 14 is coupled to the client device 12 whichin operation executes logic resources for carrying out transactions fora client. The pricing engine 18, the inventory account 16 and thetargets engine 20 are included. The targets engine 20 determines thetarget number of long and shorted shares of a security to be held by theinventory account 16. A trading engine in operation is configured toprocess at least one of client buy, sell, sell short, or buy to coverorder. For a buy order the trading engine (i) fills the buy order forboth whole and fraction shares from the inventory account 16 if there issufficient inventory in the inventory account 16, (ii) when there isinsufficient inventory completes a purchase of fraction shares firstfrom the inventory account 16 and then purchases the remainder of thebuy order from the market, and (iii) when the inventory account 16 cannot fill any of the buy order then the trading engine purchase theentire buy order from the market and in the same order purchases atarget of shares set by the targets engine 20 for the inventory account16.

In another embodiment of the present invention, a method of conductingsecurity transactions in real time provides the system 10 with theclient device 12 and an inventory account 16 and a target number ofshares. A client buy order is received from the client device 12. Theclient buy order is filled for both whole and fraction shares from theinventory account 16 if there is sufficient inventory in the inventoryaccount 16. A remainder of the buy order is purchased from the marketwhen there is insufficient inventory to complete a purchase of fractionshares first from the inventory account 16. An entirety of the buy orderis purchased from the market and in a same order a target of shares setby the targets engine 20 for the inventory account 16 is purchased whenthe inventory account 16 can not fill any of the buy order.

In another embodiment of the present invention, a method of conductingsecurity transactions provides the system 10 with the client device 12and the inventory account 16 with a target number of shares for theinventory account 16. A client sell order is received from the clientdevice 12. A whole and fraction number of the shares is sold to theinventory account 16 when a sum of the inventory account's currentbalance and a size of the sell order is less than or equal to aninventory target. Only the fraction number of shares is sold to theinventory account 16 and a whole component of the order is sent to themarket if an inventory account balance is near target and cannot buy thewhole component of the order. A size of a market sell order is increasedby 1 to reduce inventory balance when the inventory account balance hasexceeded the target.

In another embodiment of the present invention, a method of conductingsecurity transactions provides the system 10 with the client device 12and the inventory account 16 with a target number of shares for theinventory account 16. A client short sell order is received from theclient device 12. The short order is filled from the inventory account16 if there is sufficient short inventory in the inventory account 16.When there is insufficient inventory in the inventory account 16, thetrading engine completes the short sell of fraction shares first fromthe inventory account 16 and then shorts the whole component of theshort sell order from the market. When the inventory account 16 cannotfill any of the short sell order the trading engine shorts the entireshort order from the market and also shorts a target of shares set bythe targets engine 20 for the inventory account 16.

In another embodiment of the present invention, a method of conductingsecurity transactions provides the system 10 with the client device 12and the inventory account 16 with a target number of shares and theinventory account's short target for the inventory account 16. A buy tocover order is received from the client device 12. An obligation isacquired of borrowed whole and fraction number of the shares for theinventory account 16 when a sum of the inventory account's currentbalance and a size of the buy to cover order is less than or equal tothe inventory account's short target. An obligation is acquired ofborrowed of only a fraction to the inventory and a whole component ofthe order is sent to the market if an inventory balance is near theinventory account's short target. A size of a market buy to cover orderis increased by 1 to reduce inventory balance when the inventory balancehas exceeded the inventory account's short target.

In one embodiment, fraction shares are traded. The client device 12 hasa client interface that in operation is configured to receive a clientbuy, sell, sell short or buy to cover order. The host server 14 iscoupled to the client device 12 which in operation executes logicresources for carrying out transactions for a client. The pricing engine18, the inventory account 16 and a trading engine are provided. Inoperation, the trading engine processes the client buy, sell, sell shortor buy to cover order. The trading engine enables the trading offraction shares in real time as well as reduces the frequency of orderssent to market by executing principal trades against the inventoryaccount 16.

In another embodiment of the present invention, a method is provided forconducting security transactions using the system 10 with the clientinterface and the inventory account 16. A client buy, sell, sell shortor buy to cover order is processed. Fraction shares of the buy, sell,sell short, or buy to cover order are traded in real time. A frequencyof orders sent to market is reduced by executing principal tradesagainst the inventory account 16.

FIG. 13 is a flowchart for a fraction, whole share, or whole share withfraction buy order. A determination is made as to whether the inventoryaccount 16 can and should fill all, part, or none of the order. If thelogic determines that the inventory account 16 should fill the entireorder, then a real time price is received from the pricing engine 18. Toprotect against over-filling the inventory account 16 in the presence ofconcurrent real-time and/or long-standing limit orders the concept of anopen order overlay is introduced. The open order overlay is a dataresource that tracks un-executed orders that will have a net impact onthe inventory account 16 if and when they are executed. For a marketorder one hundred percent of the number of shares for the benefit of theinventory account 16 will be applied to the overlay. For limit orders,the number of shares will be discounted according to the probability offill, determined by historical volatility of the security, the limitprice, and the current market price. These factors are periodicallyrecomputed to account for price movements. Once an order completeseither by allocating shares to or from the inventory account 16 or byfilling at the market, the full quantity of that order is moved to theactual balance of the inventory account 16 and cleared from the openorder overlay.

If the order cannot be filled from the inventory account 16, thequantity of the order is rounded up and the fraction component of theorder (if any) is written to order overlay. Due to the fact that thereare often fixed costs associated with execution, settlement, andclearing, bunching system orders with customer orders to refill theinventory can represent a significant cost savings. Therefore logic isimplemented which determines whether the quantity of the order should beincreased to eagerly fill the inventory in anticipation of futurecustomer orders. The quantity of the order is increased as determined bythe logic described in FIG. 17 and described herein. The order is thensent to the appropriate market and/or market maker to execute. Anyun-priced share reservations created are priced at the same price as thewhole share order executed at the market. Finally any open order overlaycreated for this order is cleared, and the shares are allocated to thecustomer and/or the inventory account 16 as appropriate.

FIG. 14 illustrates an embodiment of the process that determines whetheror not the inventory can and should fill all, part, or none of the orderfor buy market orders. A database of security inventory held and ownedby the firms consulted to determine whether or not there are sufficientshares of the security being traded to fill the customer's order. If so,those shares are reserved for the customer. In this path no order isrouted to the market, thereby saving the system 10 the cost associatedwith executing on the open market. If it is determined that the numberof shares in the order cannot exclusively be filled from inventory, thedatabase will be consulted again to determine if the fraction piece ofthe order can be filled by the inventory account 16. If so the fractionis reserved for the customer. The appropriate return condition is sentto the outer flow depending on how many shares were reserved for theclient from the inventory account 16.

FIG. 15 illustrates one embodiment of the process that determineswhether or not the inventory can and should fill all, part, or none ofthe order for buy limit orders. If the market is open then the processcontinues and a determination is made to see if the inventory account 16can fulfill the order. If the market is not open, then the transactiondoes not process until the market opens. After-market limit orders areheld until the open when the open market price of the security can bedetermined. The inventory database is consulted just as in the case ofmarket orders. If there is sufficient inventory available, themarketability of the order is evaluated. If the order is marketable (themarket price is less than the limit price for a buy order), then theshares are reserved for the customer. If the order is not marketable, adecision is made as to whether or not filling from inventory will bemore or less beneficial to the system 10 than executing at market. Theprocess is illustrated in FIG. 16. The expected loss from executing thisorder is computed using historical stock volatility data, the limitprice, and the current market price. If the expected loss from executingat the limit price is less than the cost to go to market, the shareswill be reserved for the client. Alternatively if there are insufficientshares in the inventory to cover the entire order, the database isconsulted to see if the fraction is available. Although the cost ofgoing to market must be incurred at this point, the system 10 stillperforms an acceptable loss computation. If the loss is too high, thesystem 10 does not reserve the fraction for the client, since doing sowill preclude those shares from servicing other orders that are morelikely to fill. However if the order is highly likely to fill, thefraction will be reserved for the customer. The appropriate returncondition is sent to the outer flow depending on how many shares werereserved for the client from the inventory account 16.

Referring now to FIG. 17, in the case of a both no-inventory andfraction-only order, eager fill logic resources are run to determine ifthe system 10 desires to bunch an inventory order with the client orderto refill the inventory to its target balance in the security. If thesystem 10 determines that the net probabilistic exposure of outstandingorders (the open order overlay) summed with the current inventorybalance is less than the target, and the order is likely to fill, thenthe system 10 adjusts the order size. The inventory target, minus thecurrent inventory balance, minus the net open order overlay, is added tothe number of shares the client ordered to determine the new order size.That quantity is then written to the order overlay to prevent otherorders from over-purchasing for the inventory account 16. If the orderis unlikely to fill in the near future then no eager fill is applied, asit would preclude other orders that are more likely to fill, frombunching and filling the inventory to the target level. The probabilityis defined as 100% for market orders and for limit orders as a functionof the historical volatility as well as the limit and current marketprices.

Once the final order size has been determined through the above process,the order will be directed to the market.

FIG. 18 illustrates how the pricing engine 18 logic prices buy orders.First, the type of order is determined. If it is a limit order, then thepricing engine 18 looks at the last trade price of the stock. When thelast trade price is not less than or equal to the limit price, then thepricing engine 18 goes back and looks at the most recent trade price ofthe stock. When the last trade price is less than or equal to the limitprice, then the price is assigned as the better of the limit and marketprice. In the event the order is market order, and the market is open,the price is assigned as the ask price of a real time quote. If themarket is not open, then the pricing engine 18 waits for the market toopen before it proceeds.

The flowchart of FIG. 19 illustrates one embodiment of a customer sellflow. In this embodiment, the customer wants to sell a share-weightedportfolio. The customer receives a list of current positions and selectsa share-weighted portfolio to sell. The customer decides the sell dollaramount or decides to sell all. When the customer decides to sell all,orders are created for each security and quantity held in theshare-weighted portfolio. Orders for each security are sent to the ordermanagement system. When the sell order is for a dollar amount, marketdata is sourced for the securities in the share-weighted portfolio. Thenumber of shares to be sold from the share-weighted portfolio iscomputed for each security, while maintaining weighting and fulfillingthe desired dollar amount. Orders are created for each security andquantity and sent to the order management system.

In another embodiment, the inventory account 16 allows a client topurchase or sell fraction shares of a portfolio in real time.

In another embodiment, the inventory account 16 holds securities and inoperation executes on the purchase or sale of fraction shares ofsecurities from the inventory account 16 by the client in real time. Thetransaction of fraction shares can be done without aggregating withthird parties.

As non-limiting examples, handling fraction shares can be, (i) a clientfraction buy order when an inventory position can not fill a fraction,(ii) a fraction buy order when an inventory position can fill afraction, (iii) client fraction sell orders and the like.

As discussed above, the system 10 also provides for the selling offraction shares. Logic resources are applied for handling client wholeand fraction sell orders. In an attempt to reduce execution costs andfacilitate fraction order execution, inventory logic resources areapplied. As illustrated in FIG. 20, the system 10 routes the sell orderthrough a logic resource that decides whether or not the full order,only the fraction component of the order, or no part of the order willbe acquired in the inventory account 16. Depending on the decision fromthe flow an order overlay is created which represents the net impact ofthe order on the inventory account 16 e.g. an acquisition of shares willcause the balance of the inventory account 16 to increase.

If the full order is to be acquired by the inventory and is deemed to befilled given the current market prices for the stock, the shares areallocated to the inventory at a price determined by the pricing engine18, FIG. 21. If only the fraction component of the order is to beacquired by the inventory, the size of the order is updated e.g. for asell of 2.7 shares, 0.7 shares will be acquired by the inventory and theorder size is updated to 2 shares. No change is made to the size of theorder if the order is for a sell on a whole number of shares and theinventory will not acquire any portion of it. For the cases where theinventory will acquire nothing, the order size may be increased toeagerly sell out an inventory position that is higher than the targetfor that security. When the inventory does not acquire or it onlyacquires only the fraction component, the updated order is then sent tothe market and the price for the prior reservations is determined fromthe average fill price obtained in the market e.g., if 2 shares weresent to the market for a sell order for 2.7 shares, the allocation ofthe 0.7 shares to the inventory will be based on the average fill pricefor the 2 shares.

FIG. 22 illustrates the details of the decision process on how much willbe acquired by the inventory for a sell market order. The targets engine20 is queried to determine the current target for the security beingtraded. The open order overlay is computed for any outstanding buy andsell orders for the eventual benefit of the inventory. Determination ofthe correct target is illustrated in FIG. 24 and described herein. Ifthe sum of the current inventory balance, open overlays and the size ofthe sell order under consideration is less than the inventory target forthat security, the logic informs the outer process flow that the entiresell order will be acquired by the inventory. If the entire order cannotbe acquired, the logic checks if the inventory balance has exceeded theinventory target. If the inventory balance is in excess of the inventorytarget, the sell order is rounded up to reduce inventory risk e.g. ifthe inventory target is 10 and the balance is currently 10.5, a sellorder for 4.2 shares will be rounded up to 5 such that the inventorybalance is reduced to 9.7 (10.5−0.8) when the order is filled. FIG. 23illustrates the logic for sell limit orders. The logic first determineswhether or not the market is open. If it is not open the logic waitsuntil the market opens before proceeding. The targets engine 20 isqueried for the appropriate target for the security being traded. Thetarget, in conjunction with the net open order overlay and currentbalance, is used to determine whether or not the inventory account 16should acquire the shares. If the inventory balance summed with the openorder overlay and discounted order quantity is less than the target,then the inventory attempts to acquire the shares. If the order ismarketable, then the order quantity is reserved from the customer andthe logic returns to the outer flow that the inventory will acquire thefull amount of the order. If the order is not marketable the logicdetermines whether or not the projected loss from acquiring the sharesis acceptable. If it is acceptable, the logic returns to the outer flowthat the inventory will acquire the full amount of the order. However ifthe limit price is too high relative to the current market price, theminimal number of shares will be acquired by the inventory. In the casewhen the order has no fraction component or when acquiring the orderwould push the balance above the target, the inventory does not acquireanything and returns to the outer flow that it will acquire nothing.However if a fraction component of the order exists the fraction will bereserved from the customer and written to the order overlay. The ordersize will be reduced by rounding down to the nearest integer.

Trading logic resources are used for dynamic inventory targets. Theother cited references fail to provide for inventory targets that arebased on a probabilistic model where higher targets are set for stocksin share-weighted portfolios likely to be traded heavily and/or forstocks which have a large observed trading volume. Within ashare-weighted portfolio, relatively higher targets are set for stockswith larger weights and zero targets are set for thinly traded stocks.Dynamic inventory targets are also based on order flow. Targets aredynamically adjusted using data on client order flow.

In one embodiment, the targets engine 20 calculates a target number oflong and short shares of a security to be included in the inventoryaccount 16 to meet present and future buy, sell, sell short, and buy tocover customer orders.

In another embodiment of the present invention, a method of conductingsecurity transaction for a client, the target number of long and shortshares of a security is calculated to be included in the inventoryaccount 16 to meet at least one of, present and future buy, sell, sellshort, and buy to cover customer orders.

FIG. 24 illustrates an embodiment of the targets engine 20 operation.The targets engine 20 computes probabilities of stocks that are likelyto be traded. Input is received from, (i) a capital allocation for theinventory account 16, (ii) historical market data on dollar volume foreach stock, (iii) aggregated share-weighted portfolio order flow dataand (iv) share-weighted portfolio weights. Long and short targets arecomputed for each stock. The order management system is in real timecommunication with the targets engine 20 as it processes customerorders. The order management system and the order flow data aggregatorcommunicate order flow statistics calculated over a selected timeperiod. The order flow data aggregator provides probabilities calculatedfrom the order flow and communicates these to the targets engine 20.When queried, the targets engine 20 returns the appropriate long orshort target for the security being traded.

In one embodiment, the system 10 provides for fraction shorting, asillustrated in the flowchart in FIG. 25. A sell short order, for a wholeor a whole and a fraction of a security, is received. If the securitycannot be borrowed, then the short order is rejected.

FIG. 25 is a flowchart for a fraction, whole share, or whole share withfraction short order. A determination is made as to whether theinventory account 16 can and should allocate all, part, or none of theshort position. If the logic determines that the inventory account 16should allocate the entire short position requested, then a real timeprice is received from the pricing engine 18. To protect againstover-shorting the inventory account 16 in the presence of concurrentreal-time and/or long-standing limit orders the concept of an open orderoverlay is introduced. The open order overlay is a data resource thattracks un-executed orders that will have a net impact on the inventoryaccount 16 if and when they are executed. For a market order one hundredpercent of the number of shares for the benefit of the inventory account16 will be applied to the overlay. For limit orders, the number ofshares will be discounted according to the probability of fill,determined by historical volatility of the security, the limit price,and the current market price. These factors are periodically recomputedto account for price movements.

Once an order completes either by allocating shares to or from thecustomer or by filling at the market, the full quantity of that order ismoved to the actual balance of the inventory account 16 and cleared fromthe open order overlay. If the order cannot be filled through anallocation from the inventory account 16, the quantity of the order isrounded up and the fraction component of the order (if any) is writtento order overlay. Due to the fact that there are often fixed costsassociated with execution, settlement, and clearing, bunching orderswith customer orders to refill the inventory can represent a significantcost savings. Therefore logic is implemented which determines whetherthe quantity of the order should be increased to eagerly acquire alarger short position in the inventory in anticipation of futurecustomer orders. The quantity of the order is increased as determined bythe logic described in FIG. 28 and described herein. The order is thensent to the appropriate market and/or market maker to execute. Anyun-priced share reservations created are priced at the same price as thewhole share order executed at the market. Finally any open order overlaycreated for this order is cleared, and the shares are allocated to thecustomer and/or the inventory as appropriate.

FIG. 26 illustrates an embodiment of the process that determines whetheror not the inventory can and should allocate all, part, or none of theorder for market sell short orders. A database of security shortpositions held and owned by the system 10 is consulted to determinewhether or not there are sufficient shares of the security being tradedto fill the customer's order. If so those shares are reserved for thecustomer. In this path no order is routed to the market, thereby savingthe system 10 the cost associated with executing on the open market. Ifit is determined that the number of shares in the order cannotexclusively be filled from inventory, the database will be consultedagain to determine if the fraction piece of the order can be filled bythe system 10. If so the fraction is reserved for the customer. Theappropriate return condition is sent to the outer flow depending on howmany shares were reserved for the client from the inventory.

FIG. 27 illustrates one embodiment of the process that determineswhether or not the inventory can and should fill all, part, or none ofthe sell short order for limit orders. If the market is open then theprocess continues and a determination made to see if the inventoryaccount 16 can fulfill the order. If the market is not open, then thetransaction does not process until the market opens. After-market limitorders are held until the open when the open market price of thesecurity can be determined. The inventory database of short positions isconsulted just as in the case of market orders. If there is sufficientinventory available, the marketability of the order is evaluated. If theorder is marketable (the market price is greater or equal to the limitprice for a short order), then the shares are reserved for the customer.If the order is not marketable, a decision is made as to whether or notfilling from inventory will be more or less beneficial to the system 10than executing at market the process is illustrated in FIG. 16. Theexpected loss from executing this order is computed using historicalstock volatility data, the limit price, and the current market price. Ifthe expected loss from executing at the limit price is less than thecost to go to market, the shares will be reserved for the client.Alternatively if the short position in the inventory is not sufficientto cover the entire order, the database is consulted to see if thefraction is available. Although the cost of going to market must beincurred at this point, the system 10 still performs an acceptable losscomputation. If the loss is too high, the system 10 does not reserve thefraction for the client, since doing so will preclude those shares fromservicing other orders that are more likely to fill. However if theorder is highly likely to fill, the fraction will be reserved for thecustomer. The appropriate return condition is sent to the outer flowdepending on how many shares were reserved for the client from theinventory.

Referring now to FIG. 28, in the case of a both no-inventory andfraction-only short order logic resources are run to determine if thesystem 10 wants to bunch an inventory short order with the client orderto reload the inventory to its target short position in the security. Ifthe system 10 determines that the net probabilistic exposure ofoutstanding orders (the open order overlay) summed with the currentinventory short position is less than the target, and the order islikely to fill, then the system 10 adjusts the order size. The inventoryshort target, minus the current inventory short position, minus the netopen order overlay, is added to the number of shares the client orderedto determine the new order size. That quantity is then written to theorder overlay to prevent other orders from over-shorting for theinventory account 16. If the order is unlikely to fill in the nearfuture then no eager fill will be applied, as it would preclude otherorders that are more likely to fill, from bunching and reloading theinventory to the target short level. The probability is defined as 100%for market orders and for limit orders as a function of the historicalvolatility as well as the limit and current market prices.

Once the final order size has been determined through the above process,the order will be directed to the market.

FIG. 29 illustrates how the pricing engine 18 logic prices short orders.First, the type of order is determined. If it is a limit order, then thepricing engine 18 looks at the last trade price of the stock. When thelast trade price is not greater than or equal to the limit price, thenthe pricing engine 18 goes back and looks at the most recent trade priceof the stock. When the last trade price is greater than or equal to thelimit price, then the price is assigned as the better of the limit andmarket price. In the event that the order is a market order, and themarket is open, the price is assigned as the bid price of a real timequote. If the market is not open, then the pricing engine 18 waits forthe market to open before it proceeds.

As discussed above, the system 10 also provides for the buy to covershort positions in securities. Logic resources are applied for handlingclient buy to cover orders. In an attempt to reduce execution costs andfacilitate fraction order execution, inventory logic resources areapplied. As illustrated in FIG. 30, the system 10 routes the buy tocover order through a logic resource that decides whether or not thefull order, only the fraction component of the order, or no part of theorder will be covered from the inventory account 16. Depending on thedecision from the flow an order overlay is created which represents thenet impact of the order on the inventory account 16 e.g. covering of theshares from the inventory account 16 will cause the short position ofthe inventory account 16 to increase.

If the full order is to be covered from the inventory and is deemed tobe filled given the current market prices for the stock, the shares areallocated to the inventory at a price determined by the pricing engine18, FIG. 31. If only the fraction component of the order is to becovered by the inventory, the size of the order is updated e.g. for acover order of 2.7 shares, 0.7 shares will be covered from the inventoryand the order size is updated to 2 shares. No change is made to the sizeof the order if the order is for a cover on a whole number of shares andthe inventory will not acquire any portion of it. For the cases wherethe inventory will acquire nothing, the order size may be increased toeagerly cover an inventory short position that is higher than the targetshort position for that security. When the inventory only covers thefraction component, the updated order is sent to the market and theprice for the prior reservations is determined from the average fillprice obtained in the market e.g., if 2 shares were sent to the marketfor a cover order for 2.7 shares, the covering of the 0.7 shares fromthe inventory will be based on the average fill price for the 2 shares.

FIG. 32 illustrates the details of the decision process on how much willbe covered from the inventory for a cover market order. The targetsengine 20 is queried to determine the current short target for thesecurity being traded. The open order overlay is computed for anyoutstanding short and cover orders for the eventual benefit of theinventory. Determination of the correct target is illustrated in FIG. 24and described herein. If the sum of the current inventory shortposition, open overlays and the size of the cover order underconsideration is less than the inventory target short position for thatstock, the logic informs the outer process flow that the entire coverorder will be covered by the inventory. If the entire order cannot becovered, the logic checks if the inventory short position has exceededthe inventory target short position. If the inventory short position isindeed in excess of the inventory target, the cover order is rounded upto reduce inventory risk e.g. if the inventory short target is 10 andthe short position is currently 10.5, a cover order for 4.2 shares willbe rounded up to 5 such that the inventory short position is reduced to9.7 (10.5−0.8) when the order is filled. The logic illustrated in FIG.32 informs the outer flow that no part of the cover order will becovered by the inventory. If the inventory is at or below target, theinventory will cover the fraction component of the order e.g. theinventory target is 10 and the inventory short position is 9.7 then the0.2 fraction component of a cover order for 4.2 shares can be covered bythe inventory. The logic then informs the outer flow that the fractioncan be covered by the inventory and the order size is pared down to thewhole number only.

FIG. 33 illustrates the logic for cover limit orders. The logic firstdetermines whether or not the market is open. If it is not open thelogic waits until the market opens before proceeding. The targets engine20 is queried for the appropriate short target for the security beingtraded. The target, in conjunction with the net open order overlay andcurrent short position, is used to determine whether or not theinventory account 16 should cover the shares. If the inventory shortposition summed with the open order overlay and discounted orderquantity is less than the target, then the inventory attempts to coverthe shares. If the order is marketable, then the order quantity isreserved from the customer and the logic returns to the outer flow thatthe inventory will cover the full amount of the order. If the order isnot marketable the logic determines whether or not the projected lossfrom covering the shares is acceptable. If it is acceptable, the logicreturns to the outer flow that the inventory will cover the full amountof the order. However if the limit price is too low relative to thecurrent market price, the minimal number of shares will be covered bythe inventory. In the case when the order has no fraction component orwhen covering the order would push the short position above the target,the inventory does not cover anything and returns to the outer flow thatit will cover nothing. However if a fraction component of the orderexists, the fraction will be reserved from the customer and written tothe order overlay. The order size will be reduced by rounding down tothe nearest integer.

FIG. 31 illustrates how the pricing engine 18 logic prices buy to coverorders. First, the type of order is determined. If it is a limit order,then the pricing engine 18 looks at the last trade price of the stock.When the last trade price is not less than or equal to the limit price,then the pricing engine 18 goes back and looks at the most recent tradeprice of the stock. When the last trade price is less than or equal tothe limit price, then the price is assigned as the better of the limitand market price. In the event the order is a market order, and themarket is open, the price is assigned as the ask price of a real timequote. If the market is not open, then the pricing engine 18 waits forthe market to open before it proceeds.

FIG. 34 is a flowchart for a customer that desires to rebalance ashare-weighted portfolio and connects through the customer interface.The customer receives a list of current positions and selects ashare-weighted portfolio and an alternate weighting. The customer thendecides to, (i) add funds, (ii) remove funds or (iii) only rebalance theshare-weighted portfolio. When adding funds, market data is sourced forsecurities in the share-weighted portfolio. The system 10 computes buyand sell orders that are necessary to achieve the new weighting and addthe desired additional funds to the share-weighted portfolio. When thecustomer elects to remove funds, market data is also sourced to computethe buy and sell orders necessary to achieve the new weighting andremove the desired amount of funds. With a rebalance, the system 10computes buy and sell orders necessary to achieve new weighting with nonet cash flow. Buy and sell orders are then sent to the order managementsystem. Fraction buys and sells are achieved using the flowcharts ofFIGS. 13 and 20 and described herein.

FIG. 35 is flowchart of customer buy trigger order flow. When a customerwants to buy a share-weighted portfolio at a trigger value, the customerreceives a list of available share-weighted portfolios. The customerselects an existing or new share-weighted portfolio. With a newshare-weighted portfolio, the customer adds, removes and customizessecurity weights until the desired construction is achieved. For anexisting share-weighted portfolio, the customer selects whether to buyas-is or customize. If the customer decides to customize, securities areadded, removed, and weights are customized until the desiredconstruction is achieved. Market data is sourced for the securities inthe share-weighted portfolio and an index value is computed for theconstruction. The customer selects a trigger price that is less than theindex value and also selects the amount to be invested. This is thensubmitted as a buy trigger order. A non-customized order follows asimilar path.

The handling of buy trigger orders is illustrated in FIG. 36. Thetrigger order flow waits for the computed index value to reach thedesired limit index value. Once the index value falls below the target,the input dollar amount and the market data are used to compute theappropriate share counts to achieve the desired weighting and dollaramount invested. Buy market orders are created for each security andsent to the buy order flow as described herein.

FIG. 37 illustrates a customer sell trigger order flow. In thisembodiment, the customer wants to sell a share-weighted portfolio at atrigger value using the client interface. The customer receives a listof his or her owned positions. The customer selects an existingshare-weighted portfolio, market data is sourced for securities in theshare-weighted portfolio, and an index value computed for the ownedshare-weighted portfolio. The customer then selects a trigger price thatis greater than the current index value. Finally the customer selectsthe percentage value of the owned share-weighted portfolio to be sold.The order is sent to the sell trigger order flow.

A sell trigger order is submitted, as illustrated in FIG. 38. Sellingthe trigger order takes place when the market is open. The share weightsand current prices are used to compute the current index value. Thelogic continues to compute the current index value until the value isgreater than the trigger price. Once the trigger index value is hit thesell percentage is used to compute the number of shares to be sold foreach security and sell orders are entered in the sell order flowdescribed herein.

The system 10 also enables customers to access hedging of marketexposure or harvesting of tax losses. The trading engine is configuredto process the client hedging of market exposure or harvesting of taxlosses order and enables the trading of fraction shares in real time aswell as reduces a frequency of orders sent to market by executingprincipal trades against the inventory account 16.

In another embodiment of the present invention, the trading engineprocesses the hedging of market exposure or harvesting of tax lossesorder in real time as a single order. For a buy order the trading engine(i) fills the buy order for both whole and fraction shares from theinventory account 16 if there is sufficient inventory in the inventoryaccount 16, (ii) when there is insufficient inventory completes apurchase of fraction shares first from the inventory account 16 and thenpurchases the remainder of the buy order from the market, and (iii) whenthe inventory account 16 can not fill any of the buy order then thetrading engine purchase the entire buy order from the market and alsopurchases a target of share set by the targets engine 20 for theinventory account 16.

In FIG. 39 a customer wants to buy a hedged share-weighted portfolio.Similarly to the aforementioned buy flow the customer receives from thesystem 10 a list of available share-weighted portfolios. The customerselects either an existing or a new share-weighted portfolio. For a newmotif the customer adds or removes securities, as well as customizesweights until the desired construction is achieved. If the customerchooses an existing motif he or she will then choose whether to buyas-is or to customize the share-weighted portfolio. If the customerelects to customize they will add or remove securities, and customizeweights until the desired construction is achieved. The customerrequests a hedge for a risk exposure. Market data is sourced forsecurities in the share-weighted portfolio and for the hedgingsecurities. A number of shares is computed for each security whilemaintaining weighting and fulfilling desired dollar amount and desiredhedge. Orders are created for each security and quantity. Orders arethen sent to the order management system as described herein.

Referring now to FIG. 40, more details are provided for hedging. Aglobal risk model is computed using macroeconomic factors, valuationmetrics, and sector returns. Historical market returns andshare-weighted portfolio stocks are also use for the compute the globalrisk model. Long/short weights for share-weighted portfolio constituentsare used to compute systematic risk exposure of the share-weightedportfolio. Hedging securities are selected and long/short weights forhedging securities are computed to achieve the desired hedge. Long/shortweights of hedging securities are added to the customer's share-weightedportfolio.

FIG. 41 illustrates an embodiment of tax loss harvesting. The customerreceives a list of owned share-weighted portfolios and selects anexisting motif. Market data is sourced for securities in theshare-weighted portfolio. If the share-weighted portfolio does not havesecurities with capital losses then the client is informed that noaction is required. If the share-weighted portfolio contains securitiesthat have incurred unrealized capital losses, sell or buy to coverorders including whole and fraction shares are executed for thesesecurities. A record is maintained of the securities for which taxlosses were harvested. There is a wait until the wash rule periodelapses. A reinvestment is then made in the same securities through buyor sell short orders that include whole and fraction shares.

In another embodiment, the system 10 provides for at least one of, aclient buy, sell, sell short and buy to cover order from a customerassociated with a social media network and having at least one socialnetwork friend. A social networking engine allows customers to shareinformation for at least one of, portfolios, orders, investment ideas.The social networking engine allows users to execute securitiestransactions in real time based on the shared information. Customers areallowed to share information for at least one of, portfolios, orders,investment ideas.

FIG. 42 illustrates an example of a share-weighted portfolio order.

Other embodiments of the invention will be apparent to those skilled inthe art from consideration of the specification and practice of theinvention disclosed herein. It is intended that the specification andexamples be considered as exemplary only, with a true scope and spiritof the invention being indicated by the appended claims.

What is claimed is:
 1. A system for conducting security transactions,comprising: a client device with a client interface that in operation isconfigured to receive a client buy, sell, sell short, or buy to coverorder from a client associated with a social media network and having atleast one social network friend; a host server coupled to the clientdevice which in operation executes logic resources for carrying outtransactions for a client; a pricing engine; an inventory account; atargets engine which determines the target number of long and shortedshares of a security to be held by the inventory account; a socialnetworking engine which allows clients to share information for at leastone of, portfolios, orders, and investment ideas, the social networkingengine allowing users to execute securities transactions based on theshared information.
 2. The system of claim 1, further comprising: atrading engine that in operation is configured to process the clientorder, wherein the trading engine enables a trading of fraction sharesin real time as well as reduces a frequency of orders sent to market byexecuting principal trades against the inventory account.
 3. The systemof claim 1, wherein the social networking engine is configured toprovide that securities transactions are shared with a set of otherclients and/or one or more external social media sites.
 4. The system ofclaim 3, wherein the portfolios are share weighted.
 5. The system ofclaim 1, wherein users can communicate, collaborate, and collectivelybuild portfolios of securities.
 6. The system of claim 1, wherein thesocial networking engine is configured to provide that a client'spositions can be viewed by a configurable set of other clients.
 7. Thesystem of claim 1, wherein the social networking engine is configured toprovide that a client can comment as themselves or anonymously on aportfolio of securities.
 8. The system of claim 1, wherein the socialnetworking engine is configured to provide that a client may create orcustomize lists of friends who are clients on the system and/or friendson one or more external social network sites.
 9. The system of claim 8,wherein the social networking engine is configured to provide that aclient can adjust privacy filters to enable or prevent a sharing of theclient's positions, orders, and comments with one or more lists offriends.
 10. The system of claim 1, wherein the social networking engineis configured to provide that clients can flag other user's comments asinappropriate.
 11. The system of claim 10, wherein the social networkingengine is configured to provide that flagged comments can be removedbased on statistics about the comment, number of times it was flagged,and the clients who flagged the comment.
 12. A method for conductingsecurity transactions, comprising: providing a system with a clientdevice with a client interface, an inventory account and a socialnetwork account; receiving a client order; and using the socialnetworking engine which allows clients to share information for at leastone of, portfolios, orders, and investment ideas, the social networkingengine allowing users to execute securities transactions based on theshared information.
 13. The method of claim 12, further comprising:providing a trading engine of the system that processes the clientorder, wherein the trading engine enables the trading of fraction sharesin real time as well as reduces a frequency of orders sent to market byexecuting principal trades against the inventory account.
 14. The methodof claim 12, further comprising: using the social networking engine toprovide that securities transactions are shared with a set of otherclients and/or one or more external social media sites.
 15. The methodof claim 14, wherein the portfolios are share weighted.
 16. The methodof claim 12, further comprising: allowing users to communicate,collaborate, and collectively build portfolios of securities.
 17. Themethod of claim 12, further comprising: using the social networkingengine to provide that a client's positions can be viewed by aconfigurable set of other clients.
 18. The method of claim 12, furthercomprising: using the social networking engine to provide that a clientcan comment as themselves or anonymously on a portfolio of securities.19. The method of claim 12, further comprising: using the socialnetworking engine to provide that a client may create or customize listsof friends who are clients on the system and/or friends on one or moreexternal social network sites.
 20. The method of claim 19, furthercomprising: using the social networking engine to provide that a clientcan adjust privacy filters to enable or prevent the sharing of theclient's positions, orders, and comments with one or more lists offriends.
 21. The method of claim 12, further comprising: using thesocial networking engine to provide that clients can flag other user'scomments as inappropriate.
 22. The method of claim 21, furthercomprising: using the social networking engine to provide that flaggedcomments can be removed based on statistics about the comment, number oftimes it was flagged, and the client's who flagged the comment.